A bit more than a month ago, I had the random idea to try building and selling a web site, at the same time. The idea was that the more people bid, and requested features, the more I'd work on it. It didn't work out. I got a bit of money out of it, but certainly not enough to cover my time at an hourly rate. I suppose the lesson is that a month simply isn't a lot of time for something to mature: it'd probably be best to work on something on and off for a year, give it some time for traffic to build up, and so on, if the goal is to sell it. However, in any case, I think I'm pretty convinced that my next projects, like LiberWriter, will involve for-pay products. At heart, I'm not really a business guy, so picking the simplest possible business model probably makes sense: you pay me, I give you something. Hopefully, I'll be able to write about those in the "you win some column", but I thought I'd let people know how the experiment went.

The Kindle isn't the most beautiful device out there - it's not "beautiful", the keyboard takes away some elegance, but I'm absolutely smitten with mine. I like to read, a lot, and being able to instantly beam books to my house is just fantastic. Kindles and other devices like them are also changing the world of publishing, going from the known world of physical books that can't be easily copied to another information good like movies or songs with something of an uncertain future. Yet they're also opening up many possibilities: thanks to Amazon's Kindle Direct Publishing program, it just got very easy to publish books to a platform that a lot of people regularly search for good things to read. Once upon a time, "vanity publishing" was something done by those who simply wanted to see their names in print, but couldn't actually find a publisher, and thus carried some stigma. Now, though, why not publish something you've always wanted to? Granted, without an editor, and publisher to promote your work, you probably won't become rich or famous, but many people write for the enjoyment of doing so. And who knows... there are already several cases of people publishing directly to the Kindle and making a decent income at it. Indeed, I have several things I'm thinking of writing about that clicked when I found the Kindle publishing program. Maybe now it's time to dust off some ideas I've had and start working on them a little bit at a time. Then, of course, my geeky side took over and I started wondering how the mechanics of it actually work. Messily, it turns out: the preferred format for Kindle authoring is variant of HTML that's not at all what we're used to in these days of ever more potent CSS. The good side of it is that books mostly come out looking the same on the Kindle, and the end user can control how they want to visualize them. The bad side of the system utilized is that there are a lot of tips and tricks and little things to know about the whole process that can be annoying even for someone who knows HTML pretty well. For someone who just wants to write stuff and not worry about it, and who perhaps is not very familiar with HTML, the whole thing can be a huge mess and very frustrating. Which of course looks like an interesting challenge. I set out to work on LiberWriter.com several weeks ago, and it should be ready within the next week or two. In short, it's a system that lets you concentrate on writing and, as much as possible, tries to get out of your way in order to let you concentrate on your content. It is also targeted very specifically at the Kindle (for the time being at least), so as to really focus on making things work on that platform. For instance, it can automatically generate a table of contents, a noted pain point in writing for the Kindle. I have a number of other ideas up my sleeve too, that I'm excited to work on. I'm also definitely abandoning the "let's release it for free, for fun, and see if I can find a way to make money later" model of many past projects, and treating it like a business. I think the price I have in mind is very competitive, if you look at, for instance, conversion services that take word and spit out Kindle-specific HTML. Anyway, have a look at the site and sign up if you're interested: as soon as it's ready, I'll email and let you know. There'll be a somewhat limited trial version so that you can play around with it and see if you like it before buying the full version.

I'm working on a project that utilizes CKeditor and need to manipulate the data it contains. Since I'm familiar with jQuery and it's fairly efficient at doing that sort of thing, rather than figuring out how CKeditor manipulates things internally, I wanted to, at least to get started, access things in jQuery. There isn't a lot of information out there on the best way to do that. Here's what I figured out - it seems to work pretty well:

    var editor = theeditor();
    var contents = $("<div id='specialwrapperthing'>" + editor.getData() + "</div>");
    .... hack away with jQuery ....
    editor.setData(contents.html());

Basically, you just wrap up what the editor hands you in terms of the data, hack away on it, and then put the HTML back into the editor.

Another day, another "which ^(&^%*&*^&()* version should I use?!" with github: https://github.com/gramos/easy-fckeditor/network Github is nice, but very, very often all the forks are the very model of a modern major paradox of choice. Which one should I use? Which one is best? Do the forks exist because 1) the original author stopped bothering? 2) because the forkers just wanted to be 'cool' and have their own fork? 3) because the forkers don't have a clue about open source and don't attempt to submit their patches back? Who the hell knows, in most cases. This is frustrating. I had a random idea that might help some: if the 'network' view were able to show you, at a glance, the amount of interaction between different forks: pull requests accepted and rejected. At least we'd get an idea of what sort of community is forming around the project, and also have an idea whether the forkers and/or the authors are good open source citizens or not. Of course, as my friend Salvatore says, "pull requests are not conversations", but it's better than nothing.

Thanks to some friends on twitter, I recently discovered RailsWizard which is a very handy way of generating new Rails applications with the "right" things included. I liked what it did a lot, so I took the generated file and saved it as a github gist: https://gist.github.com/829521
Which provides me with a very handy starting place for new Rails projects. This is a great way to get some of the housekeeping out of the way before we start: ensure we're using jQuery, add some gems that I always use like exception_notifier and will_paginate, and so on.

A few weeks ago, I had an "out-there" idea to try creating and selling a site at the same time. So far, it's not exactly raking in a major amount of cash: At $100 with a couple of bids, it doesn't look like I'll be able to retire on it! That said, I haven't spent a great deal of time on it, and part of the idea of the experiment was to limit the amount of time the 'new idea' would distract me from other things. I did hope to receive a few more "audience requests" in terms of what to build on Flippa.com, though. Hopefully, things will heat up a bit during the final two weeks of the auction, but I don't think "flipping" web sites is really a business I want to be in. It's been fun to see how much you can build with how little, though, what with all the widgets and API's out there these days. Since I'm a coder at heart, I also released some Ruby code that utlizes Google's stock screener API: https://github.com/davidw/google-screener - it's under the Apache license, and is kind of neat to play around with, I think, and is what I use to fetch information for the site.

<iframe frameborder="0" marginheight="0" marginwidth="0" scrolling="no" src="http://rcm.amazon.com/e/cm?lt1=_blank&amp;bc1=000000&amp;IS2=1&amp;bg1=FFFFFF&amp;fc1=000000&amp;lc1=0000FF&amp;t=dedasys-20&amp;o=1&amp;p=8&amp;l=as4&amp;m=amazon&amp;f=ifr&amp;asins=B003YH9MMI" style="width: 120px; height: 240px; float: left; margin-right: 10px;"></iframe> I tend to be a sucker for business books, to the point where I created (and later sold) a site to discuss them. Part of the motivation for creating that site was that a lot of them tend to contain one good idea, and an inordinate amount of fluff. This book does not - it's good material that could not easily be summarized because it's full of information. I think it's actually one of the more relevant books I've ever read in that, for my situation, the idea behind it really speaks to me. I work as a consultant during the days, and I like it a lot. Rather than working on the same old thing year after year, I get to meet new people, new clients, new situations, and help them out, which is motivating. However, consulting has its downsides too, in that it doesn't create a great deal of long-term value. Once you've finished up a project, it's on to the next one, or no money comes in. I'm also a bit older and more set in my ways: I did my time in the California Bay Area, and I don't relish going back and working like mad on a "Real Startup" with VC backing, crazy hours, and having the thing consume my life. The idea behind "Start Small, Stay Small" is to find and create really niche products: stuff that will earn you some extra money as a developer, but also niches that are small enough to not really be interesting to larger companies that need a lot of income to justify a forray into a particular market segment. This, then, becomes your 'competitive advantage': Microsoft, or even 37 Signals, simply isn't going to chase after a market that is worth 20,000 dollars a year. And yet for someone working on their own, if you manage to set up something that brings in that money, and mostly automate it so that it's not a second job, it's a tidy extra bit of money. Several projects like that might even be enough to live on, depending on your lifestyle. With that in mind, the authors, Rob Walling and Mike Taper, delve into the details of how to go about doing so. The whole thing is done under the assumption that you don't have a lot of time or money to throw at things that don't bring in concrete results in relatively short order. Various subjects discussed in detail include how to find a niche, how to create a sales web site, how to measure market demand, conversion rates, how to productively outsource less critical portions of your business, and much more. They also discuss what sorts of numbers to look at for various aspects of the business, and anchor the discussion with real numbers for many things, rather than just giving you a hand-wavy phrase that's not that useful in the real world. It's not a 'timeless' book as all the concrete numbers and techniques reference technologies, sites, and the market dynamics of 2011, but after all, that's part of what makes it good. Other things I didn't like so much were being sold on their for-pay "micropreneur community", and the relatively high price of the book but I think it's worth it given the real advice you get. If you don't like marketing, and think that products succeed or fail on their merits alone, of course the book will leave you cold, but of course you're wrong about that anyway!

I often have ideas for little web sites, stuff I just get the urge to create for the fun of it. Some of them have done rather well, like langpop.com but even that doesn't make any money, and, sadly, as I age, that is becoming a more important factor in life. So I decided to try a little experiment. I was thinking some about "value" stocks, and fiddling around with Google's stock screener, and thought of the idea of a site that highlights underperforming stocks: http://underperformingstocks.com - so far so good - I went ahead and registered the domain, and put together the beginnings of a Rails application. At the same time though, I decided I have enough things to do in my evenings and weekends, so I decided that it might be interesting to start selling the site at the same time I'm building it. I'm not really sure how it will work out: perhaps people will see that there's not much there and not bid for it. Perhaps someone likes the idea behind it and is willing to buy on that. My idea, in any case, is to keep working on it as the auction progresses. As an additional twist, there are obviously a lot of features that could be added to the site, so I'll prioritize work on features suggested by users who have bid on the site. Here's the auction listing on Flippa.com: Edit: I'll also be posting updates to the twitter account I created for the project: http://twitter.com/#!/underpstocks

I'm very pleased with the Kindle; all of a sudden, I can quickly, easily, and fairly cheaply buy lots of English language books that otherwise I would have had to order (not cheap, not quick). Furthermore, they're not cluttering up my house, either! Not that I view books as clutter, but sooner or later we're going to have to move out of the apartment we're in, and the less I have to haul around, the better. However, the fact that it's not easy to share the books with my wife is starting to annoy me. I could always give her the Kindle itself to read something, but that would deprive me of not only that book, but all the others I have as well. Indeed, the difficulty of the problem lies in the difference between digital goods and physical goods. Real books are:

• "Rivalrous": if you're reading it right now, I can't very easily read it myself. Copying the book would be slow and tedious even with a good photocopier, and the copy likely wouldn't be as pleasant to read.
• "Excludable": it's pretty well established that you can't just walk out of a book store with the book without paying for it. Libraries are something of an exception to this rule, but there are limitations there as well.
• Relatively cheap to produce, in terms of marginal costs, but those costs are still certainly not zero.

Ebooks are:

• Non-rivalrous: well, without "digital rights management" or DRM, they would be. You could make as many copies as you wanted without the original copy losing anything, or without the copies being in any way 'less' than the original.
• Excludable only because of DRM. Once a DRM-free version is out there, it's very difficult to keep only paying customers from getting their hands on it.
• Have virtuall zero marginal costs: copying an ebook is extremely cheap in terms of resources.

Setting aside the costs and benefits to society of DRM, intellectual property, and so on, let's take the point of view of Amazon, book publishers and authors, who all want to maximize their income, and of readers, who want as much freedom as possible, and also, for the sake of argument, believe that paying for books leads to more money for authors, which leads to more books. I think the trick is to try and make the ebook market as similar as possible to that for real books. For instance, if you had the freedom to resell an ebook quickly and easily, the price would likely start dropping quickly, as people started selling their "used" copies of books they didn't want to keep. This would be good for the consumer, but potentially quite bad for authors, as fewer new copies would be sold. Sure, we have used book stores, but the practical limitations involved, and the fact that real books show some wear and tear, mean that there's still an incentive to buy new books. On the other hand, an ebook ought to be a bit cheaper than a real book if it's something you'd consider reading and then selling, because you no longer have that option, so the lack of freedom should be priced in to the original price. The other problem they seem to be having is with the lending of books. If you lend a real book, you can only lend it to someone who you see with some frequency, so there's already a big geographical limitation. Also, while they're reading it, you obviously can't. You have to have some trust in them, that they'll give it back to you sooner or later, so you won't just loan it to anyone: if you wanted a transaction with more finality, you'd simply sell it. Currently, Kindle books can only be lent for two weeks, and you can't access it while the other person has it. I think the latter part of that is fair, but two weeks seems like an arbitrary number. Remember though, that they don't want you to be able to just give someone a book, with no strings attached and no return-by date, because then you could also sell it, undercutting their store prices, and so on, as above. So to make lending work, they have to have some "strings attached". I think "two weeks" is a fairly arbitrary string though. What would work better? Perhaps a way that permanently differentiates the original purchaser from anyone borrowing it. For instance, a "recall now" button? This button would, when the original purchaser pressed it, disable it on the borrower's device and reenable it on the buyer's device. This would prevent secondary markets, or at least limit them, because the 'borrowed' books would be inferior to the originals. And yet it might still work well for lending; I could lend books to people who trust me without problems. Interestingly, I became aware of this site the other day: http://www.kindlelendingclub.com/ so it looks like whatever Amazon does, there are going to be tradeoffs involved. And of course, there is the point of view that all of the costs involved by DRM are too high, but that's a fairly involved discussion in its own right. What do you think?

<iframe frameborder="0" marginheight="0" marginwidth="0" scrolling="no" src="http://rcm.amazon.com/e/cm?lt1=_blank&amp;bc1=000000&amp;IS2=1&amp;bg1=FFFFFF&amp;fc1=000000&amp;lc1=0000FF&amp;t=dedasys-20&amp;o=1&amp;p=8&amp;l=as1&amp;m=amazon&amp;f=ifr&amp;md=10FE9736YVPPT7A0FBG2&amp;asins=0470929839" style="width: 120px; height: 240px;"></iframe> I got this to read on my trip to Oregon. Initially I was a bit dubious, after reading the chapter headings on Amazon. Indeed, if you read a lot of articles about tech startups, a lot of the material is not particularly novel, and are things that you've already read elsewhere. If, on the other hand, you're looking for a quick introduction to some of the common ideas behind web/tech startups, it's a pretty good list, written by a variety of people, with a lot of practical advice. The list of concepts includes "execution, not ideas", "fail fast", get feedback early", "get a co-founder", and a lot of similar advice that permeates discussions of early stage internet companies. Other people have different tastes, but for me, this passage was a strikingly effective advertisement for living in Boulder, Colorado:

With this as the backdrop, it was natural to make cycling a central part of my work with Everlater's founders, Nate Abbott and Natty Zola. Nate, Natty, and I scheduled regular weekly rides (sometimes several times a week) and while we didn't keep a formal agenda, each ride had a number of topics planned out for us to cover. In this way, we worked through many of the early challenges the business faced as it moved from idea to reality in the course of the summer of 2009. Our typical rides lasted from 60 to 90 minutes during which time we were able to focus on the business without interruption. And while getting some fresh air helps bring perspective, it's hard to avoid thinking about problems in a new way when you're out of the office, surrounded by the beauty of the Boulder foothills while your mind is completely clear. Startups, cycling, mountains... sign me up! Another tidbit I found interesting:

We often talk about the Number One startup killer at TechStars making a product for which there is no interesting market. TechStars accepts just 10 of more than 600 startups that apply and presumably they are among the best. But still, we find that at least one-third of those startups are attempting to build a product that they want, or that no one wants, instead of what the market wants But wait, I thought "execution is everything", and "ideas are worthless". It seems like avoiding bad ideas is potentially worth a whole lot of money in wasted time and energy though, no? The bit about ideas being worthless is a load of crap. The reason there is no market for ideas is that they are not "excludable". There was never a market for lighthouses either, the classic example in economics of a public good. So the government built them, and they were valuable to people operating ships. Ideas for startups may not have a lot of value compared to people executing them well, but to say they are worthless is hyperbole. In any case, though, if you're interested in startups, or especially if you happen to be interested in the TechStars program, it's book full of good advice, even if none of it will come as a revalation to anyone who follows that sort of thing regularly.

As a test project, I updated linuxsi.com (in Italian) to Rails 3. So far, I am not terribly impressed. It's nice enough, but the upgrade process was quite painful - there's a lot involved in upgrading even such a relatively simple site. Rails remains the best thing out there, as far as I can tell, in terms of programmer productivity for web projects, but at times it seems like there's a lot of taillight chasing. Upgrade this. Move to this newer, fancier, shinier system. Replace that. Sure, I suppose you can always stick with older versions, but it seems that that is a recipe for simply postponing all of the changes until a later date, when they become even more onerous. And Ruby gems don't really seem to have a mechanism to separate updates with new features from security updates, so for some things staying with older versions might be a security risk. And stuff like plugins mostly just sits there where you dumped it into your project, without any real sense of an upgrade path. I suppose I'm being a bit of a Grumpy Old Man, but at times the changes feel a bit gratuitous, and with all the breakage that Rails 3 causes, I would caution against upgrading to it for existing projects - use it for new projects to learn it. In some ways it seems to be a Ruby web framework that happens to have some compatibility with Rails. But not 99% - more like 80%, so that you'll spend 80% of your time upgrading that 20%. As one particular example, if you look at the original rails screencast, he uses <%= form_tag, with the "=". Subsequent versions of Rails dropped that, so you'd do <% form_tag .... do ... and now, with Rails 3, we're back to <%= form_tag, with the "=" again. Hrmph! Hopefully, with a bit of time, I'll see some of the nicer aspects of Rails 3.

I went ahead and got myself a Kindle for my birthday. Thanks to everyone for their comments in the last post. Here are my thoughts on it, in no particular order:
I like it a lot. I was worried that I would not actually enjoy reading with it, or that it would be significantly inferior to real books. However, I do enjoy reading with it, and I think they have achieved their aim of making it so that it 'just disappears' like a good book does. It's a very small and light device, even with the leather cover I got for it (always best with a small child in the house), so it's in no way heavy or uncomfortable. It's relatively more expensive and fragile than a copy of The Economist or a paperback, so I don't sling it around quite so casually, and do try and remember to keep it out of reach of said small child, which makes it a little less worry-free than an actual book. On the other hand, it's much cheaper than an ipad or samsung galaxy or something like that, so it's not the end of the world if something happens to it, although it would be unfortunate to be without reading material for the time it took to replace it!
The selection of material available for it is ok, but I'm just a bit disappointed - I thought offhand there were more books than there are. I regularly bump into things I might consider getting if they were available for it, but are not. On the other hand, there are quite a few books available for it for *free* because they're old and out of copyright. Stuff you might get for 99 cents at a used book store as a paperback, but it's pretty cool to be able to just zip it right to the device, for nothing at all. I am not convinced that the economics of it all has settled down yet. It's pretty absurd, for instance, that The Intelligent Investor costs nearly twice as much for the Kindle version as for the paperback! Especially since I can never resell it. I think a lot of the value I get from the device is derived from my situation: living abroad here in Italy, it's expensive and slow to get English language books, and now I can get them *instantly*, which is absolutely wonderful, and will significantly increase my reading. Also, should we ever move back to the US or elsewhere, it means a few less books to lug along or go through the sorrow of parting with. Were I in the US in a place with a decent used book store, and sure about staying in the same place for a while, I am not sure I would have bothered. I find it somehow a bit monotonous to read everything in the same form factor and with the same fonts. It takes something away from the character of a book, especially a well-done hardback. Of course, what counts is the content, but the presentation counts for something too, I think. I really do like the size and shape of the Kindle, and could see the 'smaller tablet' size catching on. Speaking of which, I'm curious to see how reading devices and tables will intersect. Clearly, a generic device that can also read books is going to be a lot more popular, but for now e-ink still has a few advantages: it's better for reading - I can stare at it much longer than I can at an LCD screen; also the battery life is much better, meaning I don't have to worry about/fiddle with charging it every day. Also, in some ways, it's nice not to have the siren-call of the web just a click away... I think though that at some point, generic devices will likely overtake dedicated readers. Who knows when, though.
Yes, it does have a browser, however, the screen refresh is so slow that I'd only really consider using it for reading web pages - wikipedia, say, rather than doing much with it. Still, I think it's nice to have and hope they continue the experiment.
Coming back to the comparison with 'real' books, I don't like the fact that I can no longer finish a book and then hand it to my wife if it's good. We could get her a Kindle too, but I'm still not sure they have the sharing thing worked out that well. 2 weeks - and then what? One way to do it might be that you can share it with anyone who you trust with one-click purchases. That'd limit it to family members or really trustworthy friends. Although... even there, I regularly loan books to friends, and would like to continue to be able to do so. Also, like I mentioned in the previous article, I'm leary of a future where my daughter doesn't have a multitude of books to peruse on our bookshelves. Bookshelves are a great way of making serendipitous discoveries that recommendation engines (those I've used at least) don't really account for. All in all, I'm very pleased with the Kindle, though, and look forward to seeing what the future holds.

Someone on Hacker News asks about the future of programming languages, and I realized that it's a pretty interesting topic. Here's my take on it: Programming languages are about people, and the compromises they may or may not make in order to communicate their intentions to computers. The technology in question may change, but there will likely always be people involved, and as long as that's true, looking at the problem through the lense of economics provides useful results. Therefore, looking at programming languages pretty much requires that you look at the economics of them:

• Network effects are important, but obviously don't squeeze out smaller languages entirely. I.e. it's good to be able to get libraries, find people to hire, books to read, friends to chat with about problems, etc... This means that future languages will have to seek out a critical mass of users.
• Since the times of Fortran, languages have been getting more efficient in terms of programmer time, because programmer time stays the same or gets more expensive, while computer time keeps getting cheaper, and language implementors keep getting better at making things fast under the hood. This means that languages of the future are likely to let you do more with less, all else being the same.
• Learning a programming language will continue to be a fairly involved process for most people, meaning that for many, it's more efficient to learn a few languages well and use them for as much as possible, rather than to try and find the 'perfect' language for each problem. This rewards general-purpose languages, compared to niche languages. This also rewards flexible languages that can be used in many different environments.
• Computers are only going to become more and more important, meaning that more people are going to want to develop the skills to work with them. Not all of them will be experts, and many may not know much, but have a vision for how a program could solve a particular problem in a field they are knowledgeable about. This means a low barrier to entry is important, because those novices will pick easier languages, become progressively more competent in them, and thus (network effects) contribute to their diffusion. Case in point: PHP. Future languages should be capable of solving hard problems, but should also make it easy to get started solving simple problems too.
• Working on languages is lots of fun, so even though there aren't necessarily monetary rewards, people will continue to play with and explore new ideas. I don't see there being a limited supply of new languages in the future.
• The costs of switching from established languages will continue to be high, so future languages will still need to interact with "legacy" languages like Cobol, Fortran, C, Java, and so on, that are so widely established in industry that systems written in them will be with us for a long time yet.

I wrote this in a hurry. Have I missed anything? How do these factors apply to languages you see emerging?

I'm thinking about getting a Kindle, and I thought I'd write down some thoughts, even if they're a bit jumbled, and invite commentary. Good: One thing I really like, living here in Italy, is that I would be able to get English language books instantaniously, and not pay shipping or import duties on them. Whatever disadvantages there may be, that is a huge advantage. Closely tied to that: if we ever move back to the US, shipping all our books will be very expensive. Having some of them in an electronic format would lighten that load considerably. It's fairly cheap. At $180, it's not something I'd want to treat carelessly, but it's significantly less expensive than various existing tables. Long battery life means it's not something you have to worry much about. E-ink looks like it's easier on the eyes than LCD screens. I'm not sure, but also its slow update speed might be a "feature not a bug" in the sense that you're not so easily distracted by the internet being just one click away. Bad: I love having real, physical books in my house. I grew up in a house full of books, and I want the same thing for my daughter. I like being able ot look through them, pick one up, and read about something. Real books are very convenient, as long as you're not lugging around hundreds of them. I like not having to worry too much about dropping them, about getting a bit of water on one or that sort of thing. You can cart them around in a backpack with little worry, take them to the beach, and so on. As far as I can tell, Knuth's books are not available for, nor would appear like they do on paper. That's the golden standard for me: once "The Art of Computer Programming" looks good on an e-reader, it will be really and truly ready. We're not there yet. It's not general purpose. Like I said above, maybe this is good for reading, but there are also times when it'd be nice to have a general purpose device, with email, maps, applications, and so on. A while back, Amazon announced some sort of beta program for a kindle SDK. I haven't heard much of anything since. So it looks like it's not really possible to code for it, which is a bit disappointing. I like to have that option available, even if I don't always exercise it. Unknown: The pricing: sometimes Kindle versions are cheaper (especially, in my case, considering shipping, and, potentially, import duties), but sometimes they aren't, which seems a bit unfair, given that you cannot sell the book if you don't like it. I'm not sure how it would work out for me in the aggregate. Digital Rights Management, or DRM, means you can't, say, sell someone a "used" ebook. This is, in some ways, understandeable, because it's not like an e-book degrades with time as a physical one might. Were it possible to sell on your old books, that might radically change the market. I could see that having both good consequences (cheaper books), but also negative ones for authors (less money). I suppose this topic merits a post or two, or even an entire book of its own, because it's a complicated subject without, in my opinion, "easy" answers. Suffice it to say, though, that there are some drawbacks, but I suppose it's also nice that Amazon "knows" which books I have, so even if I switch to a different reader, I still have my books. And it's good that authors can get paid to work on a book. Not having actually bought it yet, I have no idea how it actually 'feels' to read a book with one. I love curling up with a good book, something I certainly can't do with my laptop. The Kindle looks light and small enough that it could work, but maybe it's just too high tech and sleek to provide that same comfortable coziness. Or maybe I'm just a luddite where books are concerned?
Do you have one? Do you use it? For all kinds of books or just certain kinds (technical books, cheap 'fun' reads, whatever...)? What's the experience like?

This is definitely a "captain obvious" observation, but it's interesting to see just how much bad weather here in the Veneto is correlated with traffic to my real-time weather site, http://www.meteo-veneto.net The precipitation and insolation numbers for the month of September - as well as the radar images for the site itself - come from http://www.arpa.veneto.it/ The numbers are all normalized so as to make them easy to compare. The cloudy/dark numbers are the inverse of the insolation for the month, and could probably be fiddled with to be a bit more accurate - it's obvious that the number increases as the month goes on, with less sunlight.

I was thinking about this the other day, and I realized I can't particularly think of a label to attach to this concept. Anyone out there got a name for this? This could be due to my lack of formal computer science training, so I thought I'd ask, at the risk of looking stupid (I'm having an off day, so that's a very real possibility). If you have a series of functions, say: a(x), which in turn calls b(x), which calls c(x), and so on, and you end up with a faily long call chain, out to say m(x), and you subsequently decide that m(x) needs an additional piece of information that is contained in a local variable in the body of the a(x) function - how do you get it to m(x) ?

• You could simply make it a global variable! That's easy and generally a pretty bad idea.
• You could modify every function signature between a(x) and m(x) to look like b(x, y), c(x, y). That's a lot of work though. And what happens if something *else* needs to get passed around?
• In an object oriented language, you could make x an object, and attach y to it, so that you mostly pass it around just as before.
• Along the same lines, you could make x a hash table, so that you can look arguments up by their name, to have some idea what they are.
• You could just make x a list, and remember what position everything is in. That's not so nice though if you have to revisit the code and you didn't document where everything is, and why it's there.
• Other things? You could make a(x)'s scope visible to m(x), I suppose, although that sounds like it's a fairly involved, and potentially hairy answer.

It seems the answers are basically either 1) add the parameter to all the functions and everything that calls them, or 2) use some kind of composite type to stash the one or more values in.
It seems that this is a reasonable common thing to have to do, so it must have a name. How well does your language handle that kind of refactoring?

I don't usually talk about personal stuff here, but I'll make an exception: I got tired of telling our two year old daughter the same old stories about children lost in forests, bears, witches, evil stepmothers and so on, so I turned to some other material I know fairly well. I started recounting simplified bits and pieces of the first Star Wars movie over the course of a week. She thought it was great fun, what with wookies and robots and a princess and lots of adventures, and now, every evening, asks for "Skywalker story!". I'm quite proud, although my wife rolls her eyes a bit.

Normally, it's pretty easy in Rails to take advantage of the simple i18n tools provided. You just write I18n.t("some_key") and it'll translate that into whichever language. Today, however, I discovered what seems like a problem. If you do I18n.t(""), it returns a hash of all possible translations! And if you give it a nil, it returns an error because that's not a key in the DB. The first behavior doesn't sound correct at all, and the second seems dubious as well. I'm thinking about fixing it like so:

  def translate(key, options =  )
    return nil if key.nil?
    return "" if key == ""
    locale = options.delete(:locale)   I18n.locale
    backend.translate(locale, key, options)
  rescue I18n::ArgumentError => e
    raise e if options[:raise]
    send(@@exception_handler, e, locale, key, options)
  end

Is there any reason not to do this?

In keeping with the idea that I want to focus on things where I sell something directly to people, rather than just advertising, I am putting http://www.squeezedbooks.com up for auction on flippa.com. The auction is here: http://flippa.com/auctions/99073/Business-Book-Summary-Site
Here's what I wrote about it:

I like to read business books, but many of them contain a nugget of valuable information, and lots of fluff, because you can't sell a 10 page book. Some of them are pure fluff! Occasionally, one of them has profound implications.

I created this site several years ago in order to have a place to summarize a series of books I'd read, with the aim of creating a community interested in summarizing and, most of all, discussing business books. To be honest, that community hasn't really materialized, although there are a number of registered users (585 at last count). Most other business book summary sites are for-pay - you pay $X dollars a month and receive Y summaries. I wanted to create an open site, in order to foster discussion and communication between people reading summaries.

In any case, one baby later and in a different country, my heart isn't really in it any more, so I've decided to put the site up for sale. I still think the idea is a good one, and that in the right hands, the site could take off.
It was a fun site to work on, and really do think that in the right hands, it, or something derived from it, could be successful. I could conceivably hang on to it and keep trying different things with it, but I've decided I really need to impose this limitation of "make something to sell directly" on myself in order to avoid wandering off into "cool, but no idea how to make money" projects. Edit:
One thing that I'd like to state explicitly and publicly is that I'm not giving up on open source, just that I think I need to draw a really clear line between "I hope to make some money with this" and "this is a cool project I want to share with the world". In other words, I think I'd rather avoid the middle ground where stuff is sort of openish, and go either for projects that pay directly, or stuff that's pure open source under an Apache or BSD license. Hopefully, if I ever hit on a project that takes off, I'll be able to dedicate some time/resources to open sourcing some of the infrastructure, as I think that's currently one of the better models for producing open source software.

In the local dialect here in Padova, Italy, "ovi" means "eggs". For those who aren't native English speakers, "to lay an egg" means to fail at something or do it poorly. The connection is very appropriate.
To see what it was about, and if it was worth pursuing, I decided to submit a couple of simple applications to Nokia's OVI store. Nothing fancy, or that I'd spent much time developing, and they were actually little things I'd done for myself before the ovi.com store came out, but I had hoped to see about making a bit of money out of the time invested nonetheless.
So I went ahead and started adding them, with a quick glance the publisher guidelines. Too quick, as it turns out. A month after submitting my application, their "QA" process lets me know my application is not going to be accepted because it's not signed. Uh... yeah? Couldn't you have simply run a script on the file I uploaded to tell me the same damn thing? It's not exactly as if you have to have a human look at the file with a hex editor to determine whether it's signed or not. My phone can tell, of course - presumably Nokia ought to be able to figure it out programmatically and let me know? Sure, I should have read their big, long document prior to starting, but come on, it would have saved everyone time if their software had simply informed me that my application, being unsigned, was not ok. Now, when it comes to signing, Java ME is pretty much the worst in the business, although Apple is giving them a run for their money. At least Apple does it to make the applications good for their users (for their definition of good).

• Java ME: Ovi suggests using http://javaverified.com/ - where it costs $200 to sign up, and then something like at least 75 euros to run an application through *their* whole process. For each version. The hell with that!
• Android: you have to pay $25 to get access to the marketplace, but can self-sign applications. For free. Put that in your pipe and smoke it, Nokia & Larry.
• BlackBerry: I was sure this one was going to be expensive and painful given that BB is mostly aimed at big companies that could certainly spare the money. It's not: $20 gets you a certificate that you can sign everything you want with, and it's pretty quick and painless to get it. This is how Nokia ought to be doing things in terms of signing applications.
• Apple: $100 gets you the dev kit and then you can submit your apps to the somewhat bureaucratic and slow apple approval process. Plus you have to own a mac to develop on, if you don't already have one. But still, only $100 a year, and you can do as many apps as you want.

So there you have it, Java ME involves more fees than the other ones, and is probably as slow and bureaucratic to boot. I'm not going to find out, though, this pretty much concludes my experiment with ovi.com - there's no way I'm going to spend all that money on a little fun application that I'd only sell for a few euros. Being a fan of open source and openness in general, my next phone will certainly be Android based. I think someone at Nokia probably realizes things are broken: they appear to be working on a way to make it not cost anything to sign Symbian apps. But I don't have a Symbian app, so that's pretty useless for me. Oh, and while I'm bitching about their whole process, their publisher interface was down all of last weekend in order to "add a new set of metadata which will improve the Ovi Store user experience". It took a whole weekend of downtime to add that?
Furthermore, I signed up for Ovi as soon as it came out - I was going to push Hecl to it (but didn't bother at the time) but now it appears they want 50 euros from you just to sign up. Here's a hint: save your money.